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METHOD AND SYSTEM FOR FORMING DYNAMIC 
VENDOR COALITIONS IN COLLABORATIVE 

e-COMMERCE 

DESCRIPTION 
5 BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention generally relates to electronic marketplaces 
(e.g., e-commerce) where buyer requirements cannot be met completely by 
any single vendor and, more particularly, to a method and system for forming 
1 0 dynamic vendor coalitions to deliver the customer requirements jointly. 

Background Description 

In today's dynamic net-generation business environment, the window 
of opportunity is shrinking for many businesses due to the time and space 
compression effect of the Internet. In the face of intense competition, 

1 5 businesses are faced with the need to rapidly re-configure themselves over and 
over again as they strive to introduce new products and processes. Many 
businesses find that they are unable to fully respond to demands of the 
marketplace because of limited capabilities, limited capacity, range of 
products, location or other limitation. Such businesses may, however, be fully 

20 capable of responding at least partially to the demands and would like to 

participate in a response if they could find a suitable partner or partners. 
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SUMMARY OF THE INVENTION 



It is therefore an object of the present invention to provide a way for 
multiple businesses to effectively respond to demands of the marketplace in a 
way that allows businesses to remain competitive without the need to rapidly 
5 re-configure themselves.. 

According to the invention, there is provided an alternative to business 
re-configuration, namely formation of dynamic alliances. Dynamic networks 
of alliances (or coalitions) are formed between vendors with complementary 
capabilities to jointly pursue specific market opportunities. Such alliances are 
1 0 created primarily for the purpose of satisfying a market opportunity and 

disbanded after the opportunity has been satisfied. Although most alliances 
will be short-term in nature, traditional long-term business relationships can 
also evolve in some cases. 

The invention is a process and a system for forming dynamic vendor 
15 coalitions from a pre-qualified set of vendors. It is assumed that the input for 

vendor coalition formation is a pre-qualified set of vendors generated by other 
matchmaking and filtering processes. Forming vendor coalitions involves 
multi-objective optimization, where the objectives might conflict with each 
other. Examples of such multiple objectives include: 
20 1 . Meeting customer requirements at lowest cost; 

2. Delivering customer requirements in the shortest possible time; 

3. Forming coalitions that have the highest group dynamic coefficient; 
and 

4. Meeting customer requirements using vendors from a specific region. 

25 This invention can be used in electronic marketplaces where buyer 

requirements cannot be met completely by any single vendor. In such a case a 
coalition of vendors can be formed to deliver the customer requirements by 
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jointly leveraging the capabilities of individual vendors. Such requirements 
are common in project-oriented industries where development of engineered- 
to-order products and services is quite usual Here a system integrator works 
with vendors specializing in various capabilities and puts together a proposal 
for the customer. Another potential area for use of this invention would be for 
new product or new service introduction (NPI) into a market, irrespective of 
industry. Here a company with an idea can rapidly assemble a team of 
specialists to convert the idea into reality. The NPI process again usually tends 
to be very project-oriented in nature. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advantages will be better 
understood from the following detailed description of a preferred embodiment 
of the invention with reference to the drawings, in which: 

Figure 1 is a block diagram illustrating the vendor coalition formation 
and selection process; 

Figure 2 is a block diagram illustrating vendor coalition formation in a 
multi-level RFP tree; 

Figure 3 is a block diagram which shows in more detail the system- 
supported coalition formulation process according to the invention; 

Figure 4 is a block diagram illustrating project decomposition into sub- 
projects at several levels; 

Figure 5 is a block diagram showing RFP transmission from a 
customer to vendors; 

Figure 6 is a block diagram illustrating the process of splitting a RFP 
into sub-RFPs; 

Figure 7 is a block diagram showing an example of primary vendor 
selection for sub-RFPs by Vendor (2) based on vendor responses (proposals) 
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to sub-RFPs; and 

Figure 8 is a block diagram showing the response of Vendor (2) to the 
customer on behalf of coalition C2. 

DETAILED DESCRIPTION OF A PREFERRED 
5 EMBODIMENT OF THE INVENTION 

Referring now to the drawings, and more particularly to Figure 1, there 
is shown an overview of the single-level, vendor coalition formation problem 
between a customer and several vendors. An incoming buyer request, or 
request for proposal (RFP), is converted into a set of demanded capabilities 
10 DC1, DC2, . . ., DCN through capability translation 101. Demanded 

capabilities (DC) are those that are necessary to address the requirements 
presented in the RFP and provided by one or more vendors. For each 
demanded capability, a set of potential vendors is selected through vendor 
matchmaking functions 102 1? 102 2 , . . 102 N to whom invitations can be sent 
15 out. Thus, for example, the vendor matchmaking function 102 x generates a set 

of vendors 103, which includes vendors VI, V2 and V3, the vendor 
matchmaking function 102 2 generates a set of vendors 103 2 which includes 
vendors VI, V3 and V4, and the vendor matchmaking function 102 3 generates 
a set of vendors 103 3 which includes vendors V5 and V6. The coalition 
20 formation process determines one or more coalition alternates 104 1? 104 2 , etc. 
from which an optimal group of vendors 105 for each of the demanded 
capabilities is determined. 

There are a few points to observe regarding this process: 
1. Each demanded capability in the set DC1, DC2, . . DCN will have a 
25 shortlist of selected vendors who have been selected on the basis of 

matching their known (registered) capabilities with demanded 

capabilities. 
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2. - One vendor may be able to provide more than one demanded 

capability as pictorially depicted in Figure 1. Vendor VI can provide 
demanded capabilities DC1 and DC 12. 

Here, the formation of vendor coalitions when one vendor provides more than 
5 one demanded capability is a complex problem. In Figure 1, two potential 

solutions for the coalition formation problem are: 

1 . Select VI to satisfy both DC1 and DC2, and select V5 to satisfy DC3. 

2. Select VI for DC1, V2 for DC2, and V5 for DC3. 

Assuming that these vendors have sufficient capacity to meet the imposed 

10 demand, both of the above solutions are feasible. However, the cost associated 
with them may not be the same. The total cost of solution 1 might be lower 
because VI provides a lower price on the combined bid for DC 1 and DC2. 
Also, solution 2 might be delivered quicker because three different vendors 
who take a smaller amount of time together to satisfy all demanded 

15 capabilities. It is immediately apparent that there a combinatorial number of 

feasible solutions exist for the coalition formation problem, each with an 
associated cost or duration to deliver. Developing an optimal solution will 
involve searching the entire space of solutions which can be prohibitive in 
terms of computation time. Therefore, implicit solution space spanning 

20 techniques are developed to solve this decision support problem. 

As shown in Figure 2, when incoming RFX (i.e., request for proposal 
or request for quote) requirements are complex, they can be broken down into 
smaller sets of requirements. This task is usually performed by a systems 
integrator 201. The incoming RFX is split into multiple RFXs based on some 

25 criteria. The systems integrator 201 generates sub-RFXs, illustrated in 
Figure 2 by way of example only as sub-RFPl 202! and sub-RFP2 202 2 , 
which are then passed on to down stream capability translation, again 
illustrated in Figure 2 by way of example only as capability translation 203! 
and capability translation 203 2 . These translation functions produce demanded 
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capabilities DC2, DC2, DC3 and DC4, DCS, DC6, respectively. Vendor 
matchmaking functions 204j to 204 6 then generate sets of vendors 205 , to 205 6 
which are passed to the coalition formation processes. In this situation, vendor 
coalitions are of a hierarchical nature depending on how many RFXs the 
5 original RFX generated. In this case, there are two categories of coalitions: 

1. Single-level coalitions that are formed to meet requirements of each 
parent RFX node in the RFX tree. At each level in the tree, a vendor 
coalition can be generated that optimally meets the requirements of the 
parent RFX node. 

1 0 2. The overall multi-level coalition for the total project (based on the 
incoming customer RFX) that incorporates all hierarchies. This 
essentially is a hierarchical aggregation of all single-level coalitions in 
step 1. 

Multi-level coalition formation in the hierarchical situation can be 
15 based on decisions that can be either local or global in scope. When coalitions 
are formed based on local scope, local information within the current level in 
the tree is used to optimize the coalition at the current node. Results are then 
passed back to the parent node. Finally, the multi-level coalition that results is 
obtained by aggregating the results of the local coalitions at each individual 
20 node in the tree. 

When vendor coalitions are formed globally, no coalition formation 
decisions are made at the local level. Based on the vendor selections 
performed during the matchmaking process, invitations are sent out. Based on 
the vendor responses received, global optimization may be performed by 
25 looking at the entire tree to decide how coalitions will be formed at each level 
in the tree rather than making decisions at individual nodes and then 
aggregating the results. 

The overall coalition formation process is shown in Figure 3. An RFP 
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received from a customer at 301 is reviewed by the system integrator 302 at 
Level (n) for project details, and then the project is decomposed into sub-RFPs 
at 303. The system illustrated in Figure 3 comprises several databases, 
templates and tools. Specifically, requirement templates 304 are used to create 
RFPs for sub-projects 305 l5 305 2 and 305 3 . In the process of creating these 
RFPs, an RFP database 306 is accessed by the system, and for each RFP 
created, the system determines at 307 ls 307 2 and 307 3 required capabilities and 
matches vendors to those capabilities by accessing vendor capability database 
308. After vendor short lists are prepared at 309 u 309 2 and 309 3 , vendor 
proposals are solicited at 310 1? 310 2 and 310 3 , and the received proposals are 
stored in proposals database 311. The vendor proposals in database 3 1 1 are 
accessed by the negotiation tool 312 used by the system integrator 302 to 
negotiate proposals at 313 l5 313 2 and 313 3 . Primary and alternate vendors are 
selected at 314 t , 314 2 and 314 3 using the decision support tool 315. Once the 
project coalition for a given coalition level is formed at 316, the coalition is 
stored in the coalition database 317. When the customer accepts the proposal, 
the system rolls up the coalition at Level (n) to the Level (n - 1) coalition at 
318, thereby aggregating it within the larger coalition. 

The steps illustrated by numerals within parentheses in Figure 3 are 
implemented by the system. In step (1), the Vendor (n) receives an RFP from 
the Customer (n). In step (2), the Vendor (n) reviews the project requirements 
in the RFP. The Vendor (n) then decomposes the project into sub-projects in 
step (3), if necessary. The overall structure of project decomposition into sub- 
projects at each layer is shown in Figure 4. 

Referring to Figure 4, the customer project at Level ( 0) is decomposed 
into sub-projects 11,12 and 13 at Level (1). Each of these sub-projects may be 
further decomposed into further sub-projects at lower levels so, for example, 
sub-project 11 maybe decomposed into sub-projects 111, 112 and 113 and 
sub-project 13 maybe decomposed into sub-projects 131 and 132 at Level 3. 
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Returning now to Figure 3, in step (4) Vendor (n) creates sub-RFPs 
based on the Customer (n) RFP, if necessary. Vendor (n) is now Customer 
(n+1) in the context of a sub-RFP. Note, if Vendor (n) has all the capabilities 
in-house to satisfy Customer (n) RFP, then there may be no need to create 
5 sub-RFPs. In some instances, even if Vendor (n) lacks certain capabilities, the 
Vendor (n) may choose to go outside the system to get services, essentially 
forming private coalitions in response to the Customer (n) RFP. This 
represented in step 3 a in Figure 3. The process of splitting RFPs into sub- 
RFPs is shown in Figure 5. 

1 0 In Figure 5, the customer RFP (0) is analyzed by the data processing 

system to determine demanded capabilities. This processing includes 
requirements translation 501, capability matching 502 and soliciting proposals 
503 from vendors. This last step is shown by sending the RFP (0) to a 
plurality of vendors 504 1? 504 2 and 504 3 . 

1 5 Again with reference to Figure 3, The system determines in step (5) 

the capabilities required to satisfy sub-RFP requirements, if sub-RFPs are 
input to the system. The system matches required capabilities identified with 
available vendor capabilities. The system then creates in step (6) a vendor 
shortlist in response to a sub-RFP. The shortlist vendors are designated as 

20 belonging to Vendor (n+1) category. The system then invites vendors on the 
shortlist to review the sub-RFP and provide a proposal in step (7). The entire 
process of RFP Transmission from the customer to the invited vendors is 
shown in Figure 6. 

Figure 6 shows the initial RFP (0) going to Vendor 1, Vendor 2 and 

25 Vendor 3, and each of these vendors splits the RFP (0) into two or more 

sub-RFPs. Taking Vendor 2 as exemplary, the RFP (0) is split into RFP (21), 
RFP (22) and RFP (23). Each of these sub-RFPs are submitted to one or more 
vendors. In the illustration, RFP (21) is submitted to Vendor 211, Vendor 212 
and Vendor 213, RFP (22) is submitted to Vendor 221, Vendor 222 and 
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Vendor 223, and RFP (23) is submitted to Vendor 231, Vendor 232 and 
Vendor 233. 

Referring back to Figure 3, Customer (n+1) reviews Vendor (n+1) 
proposals in step (8). The system facilitates negotiation of the proposal 
5 between Customer (n+1) and each of Vendors (n+1). Then, in step (9), the 
customer selects primary and secondary Vendors (n+1) to provide the sub- 
RFP solutions as shown in Figure 7. 

In the example of Figure 7, Vendor 2 selects Vendor 212 who 
responded to sub-RFP (21), Vendor 221 who responded to sub-RFP (22), and 
1 0 Vendor 23 1 who responded to sub-RFP (23). 

In step (10) Figure 3, Vendor (n), who is also designated as Customer 
(n+1), and primary Vendor (n+1) become part of a coalition in support of 
Customer (n). This is a Level (n) coalition. Vendor (n+1) may have its own 
coalition at Level (n+1). This is rolled up into the Level (n) coalition if 
15 Vendor (n)'s proposal is accepted by the customer. If multiple sub-RFPs are 
created by Customer (n+1) (i.e., Vendor (n)), then several Level (n+1) 
coalitions may be part of the Level (n) coalition. In step (11), Vendor (n) 
provides a proposal to Customer (n) on behalf of the Level (n) coalition as 
shown in Figure 8. 

20 In the example shown in Figure 8, Vendor (2) responds to the 

Customer on behalf of coalition C2. This coalition comprises Vendor (2) in 
combination with Vendor (212), Vendor (221) and Vendor (231), these latter 
vendors having been selected in the process illustrated in Figure 7. Likewise, 
Vendor (1) responds to the Customer on behalf of coalition CI, and Vendor 

25 (3) responds to the customer in behalf of coalition C3. 

It should be noted again that Vendor (n) need not create sub-RFPs and 
coalitions as required by the system-supported process in order to create a 
proposal for Customer (n). Qualified vendors could create a private coalition, 
as shown in step (3a) in Figure 3, in preparation for submitting the proposal. It 
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is also possible for Vendor (n) to provide the proposal first and then create the 
Level (n) coalition (either system-supported or private) to deliver the RFP 
solution unless, of course, the coalition's description is required as part of the 
proposal. 

5 In summary, the invention facilitates a coalition formation process 

when a customer brings a RFP to the e-marketplace. The system gathers the 
requirements, analyzes the requirements to determine the capabilities required 
for the job, and then compares the required capabilities to a vendor capability 
catalog. A shortlist of potential vendors is generated, and this list may be 

10 further refined to account for customer and vendor preferences. Each vendor 

on the shortlist is invited to prepare a RFP response. Each vendor invited to 
respond in turn assesses the RFP requirements, identifies the capabilities 
required, and if necessary decomposes the RFP into a plurality of sub-RFPs. 
When the RFP is decomposed into one or more sub-RFPs by a vendor, the 

15 vendor becomes a customer, and the sub-RFPs are processed in a manner 

similar to that of the original RFP to generate a shortlist of potential vendors 
for each of the sub-RFPs. Sub-vendors with all the required capabilities can 
prepare proposals and the vendor, acting as a customer, can assess the 
proposals and select one or more sub-vendors to form a coalition. The vendor 

20 then presents a proposals to the original customer. The customer receives 

proposals from a plurality of vendors, who may represent one or more 
coalitions of vendors, and selects one or more of these to fulfill their 
requirements. In the context of a project, any organization can simultaneously 
play one or more roles; i.e., that of a customer, a vendor, or in some cases 

25 even a sub-vendor. 

The process supported by the invention has the advantage of repeat 
business from customers because they receive services from the best team 
available at the time of their request. The vendors, in turn, are able to respond 
to customer RFPs that they might not otherwise been able to respond to. 
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While the invention has been described in terms of a single preferred 
embodiment, those skilled in the art will recognize that the invention can be 
practiced with modification within the spirit and scope of the appended 
claims. 
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